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We introduce a simple microscopic description of software bug dynamics where users, 
programmers and a maintainer interact through a given program, with a particular 
emphasis on bug creation, detection and fixing. When the program is written from 
scratch, the first phase of development is characterized by a fast decline of the number of 
bugs, followed by a slow phase where most bugs have been fixed, hence, are hard to find. 
Releasing immediately bug fixes speeds up the debugging process, which substantiates 
bazaar open-source methodology. We provide a mathematical analysis that supports our 
numerical simulations. Finally, we apply our model to Linux history and determine the 
existence of a lower bound to the quality of its programmers. 
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2 MICROSCOPIC MODEL OF SOFTWARE BUG DYNAMICS: 
1. Introduction 

The importance of reliable software is obvious nowadays, as computers control an 
growing part of our life. At the same time the complexity of software is ever in- 
creasing. A particularly important problem is the management of software projects 
so as to minimize development cost or release software on time, while ensuring the 
quality of software. Appropriate methodologies of programming and team synchro- 
nization are designed to avoid errors in the first place 1,2 , but it is common wisdom 
that software development goes through a cycle of trial and errors and that it is 
very hard to estimate the overal quality of software and the time needed to deliver 
a well-tested product. Theoretical approaches of software reliability are done via so 
called reliability growth models, which focus on how much errors a program con- 
tains, that is, the failure rate, or the time between two failures, with a particular 
emphasis on predicting these quantities (for a review, see Lyu's book 6 , Chapter 3). 
There is a hierarchy of approaches: early studies are of macroscopic nature: one 
measures the evolution of a quantity that depends on the errors in a given program, 
such as the time to next failure. In order to make useful predictions, one uses 
fitting functions, also known as models. A more recent approach is mesoscopic, 
that is, splits a program in several modules, each having their own propensity to 
fail. Remarkably, the evolution of the global failure rate is universal, and the latter 
decreases as power- law, that is, very slowly 4,5 . 

Our work supplements current vast litterature on the topic 7 by describing what 
happens when a bug is fixed. Indeed, almost all the reliability growth models assume 
that a bug is fixed as soon as it is detected and that doing so nothing else is broken. 
We propose to remedy that by using a simplified microscopic framework where the 
fundamental unit is the software bug, not code units modules or even submodules. 
Doing so, one may indcntify fundamental microscopic laws, and above all, the cru- 
cial ingredients of software reliability: in this paper, we not interested in predicting 
reliability, but in understanding on what microscopic processes it depends. Starting 
at the microscopic level and being able to compute analytically what macroscopic 
properties emerge brings much insights: a large part the success of modern Physics 
come from the development of microscopic models and mathematical methods for 
dealing with a great many of elementary units. What is meant by model is not a 
fitting function, that is, an arbitrary a priori relationship between measurables that 
fits more or less convincingly data, but how elementary units are born, interact 
with each other or with external constraints, and die. Such microscopic models are 
usually much simplified, but capture the essence of a given situation because they 
contain the most fundamental interactions that give rise to relevant phenomenol- 
ogy. For instance, a atom of iron contains 26 protons, 26 neutrons and 26 electrons, 
each in interaction with each other and with those of the neighbouring atoms; in 
order to understand how microscopic interactions lead to magnetism, a collective 
phenomenon, it is enough to replace each atom with one binary variable and assume 
a nearest-neighbour interaction. This is the path that we propose to follow in this 
article. Our aim is to keep the most important microscopic interactions in a very 
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simple and extendable framework that allows for more realistic ingredients to be 
added if need be, but that should reproduce qualitatively important properties of 
software quality evolution. The number of parameters must be very small, other- 
wise one is very likely to be unable to understand the relative importance of each 
ingredient. 

Our model shows that software projects can converge to a bug-free state even 
with imperfect programmers and maintainers. However, if there is any number of 
users that fill bug reports on imaginary problems and if the programmers modify 
the code without double- checking, the bug-free state is not a fixed point of the 
dynamics. Our model is also able to explain why programs whose source code 
is openly available, the so-called open-source software (OSS) 9 , are able to reach 
a high quality, despite the fact that its programmers are sometimes less skilled 
than those working for closed-source software (CSS) companies. OSS has become 
quite relevant because of the rise of successful open-source project such as Linux 10 
or Apache. 11 There are broadly speaking two types of open source projects, often 
called bazaar and cathedral, as put by Raymond. 12 Bazaar projects such as Linux 
release new versions "early and often", and welcome contributions by everybody, 
while cathedral projects release new versions at a lower pace, and are crafted by a 
smaller group of programmers. In that respect cathedral OSS stands between CSS 
and bazaar OSS. 

2. Definition of the model 

Our approach is to create a minimal model, that does not describe in all its sub- 
lety how software testing is done, but the microscopic processes of bug discovery 
and elimination, which arc remarkably absent from current literature, where it is 
assumed that a bug is corrected immediately when discovered. Being minimal, this 
model allows for easy addition of relevant extensions; we shall discuss some of them 
in the Outlook Section. 

In our model, a program is defined as a collection of L parts i = 1, • • • , L, or 
modules; a part provides a basic functionality such as file loading. Each part has 
M subparts. The total number of subparts LM will be referred to as the size S of 
the project. We shall make the assumption of independence, which means that if a 
given (sub)part is buggy, the other (sub)parts are not affected; this is clearly not the 
case in real life, as bug influence propagate 17 on the functional/object dependence 
network 16 (see also 6 , Chapter 13, pp 538). Another assumption is that all the parts 
have the same number of sub-parts; this is a less important assumption that can 
be easily remedied by assuming a probability distribution function for the number 
of subparts of each part i, denoted by Mi, which would increase the number of 
parameters of the model. 

Let us introduce some important notations that characterize the state of the 
program at time t. Subpart j of part i (j = 1, • • • , M) is either bug free — in which 
case its state is denoted by Sij(i) = — , or buggy (sij(t) — 1). A feature request 
is considered as a bug. At time t, part i has bi(t) = J2j=i s »,j(*) bugs, and the total 
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number of bugs is B(t) = 5Z i=1 bi(t). Finally, the number of defective parts, i.e., 
those having at least one bug is D(t) = Yn=i @( b i(t)) where Q(x) = 1 if x > and 
otherwise, is the Heaviside function. 

The dynamics of the program results from the interaction between those who use 
the program, detect bugs and complain about them, and those who try to correct 
them. To this end, we consider N u users. At each time step, each user is assumed 
to use one part, say, i, chosen at random, and to report a buggy behavior with a 
probability P u that depends on fraction of bugs in part i: this corresponds 

to the assumption that all the subparts are equally likely to be used in a time-step. 
Instead of assuming that P u is a generic function of bi/M, we shall only retain its 
first order term: 

The parameter 6 describes the fraction of subparts used in a time-step, and also 
includes the propensity of the users to report bugs. Interestingly, keeping the zero- 
th order of P u is akin to suppose that the users report bugs erroneously. Previous 
work assumed that P u = est. 8 In our view, P u must contain a feedback from the 
actual number of bugs, otherwise bug reporting is a process completely disconnected 
from the actual program. 

Each bug report only consists of the number of the buggy part because the user 
cannot describe in more details where the program is faulty. The bug list is hence 
a table indicating which parts are reportedly buggy, and its length is R(t). It is the 
medium of interaction between the users and the programmers. 

There are N p programmers. In addition to hunting bugs according to Eq. (1), 
each of them tries to correct one part chosen at random from the bug report list, 
say, i, and reviews all the subparts of part i. This process is assumed to fix a 
buggy subpart with probability <fi and to break a working subpart with probability 
(3; Mathematically, 

P[s id (t+1) = 0\s id (t) = 1] - 0, P[s id (t+1) = l\s id (t) =0} = P Vj = 1,- • • ,M. 

(2) 

The parameters <f> and (3 encode the programmers' abilities, which are chosen to be 
uniform; once again, this assumption does not change qualitatively the properties of 
the model; it is very simple to introduce heterogeneity here, at the cost of additional 
parameters. In the simplest version of our model, the programmers implement 
directly the modifications to the source code. In practice however, in larger projects, 
the programmers propose these modifications (so-called patches) to the maintainer. 

The role of the maintainer is to determine whether a patch improves the code 
or not. The maintainer measures the number of bugs in the current code hi and in 
the modified code b\. He decides to accept the patch if he perceives that the patch 
is an improvement {b [ <bi), and removes part i from the bug list. The measure is 
made as follows: he reviews the code of all sub-parts of part i, and detects correctly 
a buggy sub-part with probability v, and a working sub-part with probability u). 

How to estimate j3, <ft, v and u> from real data is discussed in section 
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This completes the definition of the model: the creation, detection and removal 
of bugs arc fully specified, as are the interactions between the users, programmers, 
maintainer and the code. There is however a subtle point: the users are implicitely 
assumed to use always the latest version of the program. The time has come there- 
fore to differentiate between open source and closed source projects. One of our 
aims is to show where the difference lies between these two strategies, and to this 
end, one is allowed for making it more pronounced by suitable assumptions. Bazaar 
open source projects release "often and early" new versions; running the latest, or a 
very recent, version of a given program is easy and probably quite common. Closed 
source projects on the other hand, do not release as nearly as often new versions, 
because they tend to prefer to release well-tested version whenever possible. The 
cost of new versions of commercial software also deters a fraction of the users to 
upgrade systematically. In summary, because of the very nature of these two devel- 
opment processes, all other things being equal OSS users necessarily upgrade faster 
than CSS users. This is translated in our model in the following way: OSS users 
always use the latest version, while CSS users upgrade every T time steps. T in- 
cludes the lesser propensity of CSS to upgrade and the time between two releases; 
for the sake of simplicity, we shall speak of releases every T time steps. The CSS 
users continue to report bugs of the latest release, while the CSS programmers work 
exclusively on the yet unreleased code. One objection to this hypothesis is that in 
real life there are alpha and beta testers, which greatly help the CSS programmers 
to hunt bugs. While this is correct, it is obvious that the number of alpha and 
beta testers is smaller than N u , thereby reducing the ability of detecting bugs. In 
addition, we shall only study comparable situation, hence the all other things being 
equal mention. Nothing prevents the extension of our model to alpha/beta testers 
and to simulate various project configurations, but this is beyond the scope of the 
paper. 

In closed-source projects, the programmers are faced with a dilemma when a 
part is reported as buggy by a user after it has been already tentatively fixed 
since the last release. Indeed, the users report bugs on the last release, whereas the 
programmers work on the next one, both gradually diverging. The programmers can 
either ignore bug reports on an already modified part, or modify again the current 
code. In the latter case, the modification can be systematic, or after verification 
that the part in the current code is also seemingly buggy (according to Eq. (1)). 
Without verification, D(t) is not a monotonically decreasing quantity, as a newly 
bug-free part can be partly broken by this process. 

Finally all the parameters of this model can be changed at each time step, and 
will be in Section 4, thus 

3. Results 

We shall first report numerical experiments and then propose qualitative ana- 
lytical explanations of the observed behaviours. Our aim is not to validate our with 
real-life figures, but to check whether it behaves reasonably, and what parameters 
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Fig. 1. Number of defective parts (left panel) and number of bugs (right panel) in an open source 
project (continuous lines), closed source projects with no bug report resubmission allowed between 
releases (dashed lines) L = 100, M = 20, N u = 100, N p = 10, S = 1, </> = 0.9, (3 = 0.1, ui = 0.9, 
v = 0.9. T = 1 for OSS and T = 50 for CSS. 



are the most important for improving the quality of a software project. 

Fig. 1 reports the typical dynamical behavior of projects that start from scratch 
(sjj = 1 for all i and j): the number of defective parts D(t) oc exp(— Xt) for large 
t, as often assumed in reliability growth models. 1 At a more microscopic level, one 
can distinguish two phases: in the early easy stage, the users find and report many 
bugs, keeping R(t) » N p . The vast majority of bugs are fixed during this phase, 
where B(t) decreases linearly with time. When R(t) <~ N p , a slow regime appears, 
where B{t) ~ exp(— t/r); in this regime, the average number of bugs per defective 
part B(t)/D(t) is small and fluctuates around a value that depends on the chosen 
parameters. 

Ignoring bug reports on already modified code is the best option for CSS; this 
even outperforms OSS at short time scales, because the programmers only work 
on fully buggy parts, hence the bug fixing rate is higher (right panel of Fig. 1). 
Verification is generally a bad idea when bugs are sparse, because the probability 
that both a user and a programmer agree that a part is buggy is small, hence 
verification slows down the process. 

The global temporal evolution can be characterized by the time to completion, 
i.e., the time needed to obtain a bug-free project, denoted by t c . We shall investigate 
in particular its average (t c ) over several runs. For the sake of speed, we stop the 
simulations when B(t) = 1: since the decrease of B{t) is exponential in this phase, 
(t c ) would be roughly doubled if one waited until B = 0. 

The average time to completion increases roughly linearly with T (Fig 3), hence, 
closed source projects are always slower to reach a perfect state than open source 
projects, all other parameters being equal. The reason why increasing T penalizes 
the performance of the project is obvious from Fig 2: after each release, the num- 
ber of relevant bug reports coming from the users falls rapidly to zero, and the 
programmers are left on their own; as a consequence, the fast and slow regimes 
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Fig. 2. Dynamics of the number of bugs and bug reports in closed source projects (T = 500). 
L = 1000, M = 40, N u = 1000, N p = 10, S = 1, </> = 0.9, /3 = 0.1, u> = 0.9, v = 0.9 



Fig. 3. Average time to completion t c as a function of the time between releases T. Full symbols: 
L = 1000, M = 10, empty symbols L = 2000, M = 5; N u = 100, N p = 10, 8 = 1, = 0.9, /3 = 0.1, 
u = 0.9, ^ = 0.9 average over 100 runs. 




Fig. 4. Average time to completion (t c ) as a function of the number of subparts per part M at 
constant size LM = 1000 for open source projects (full circles), closed source without bug report 
resubmission between two releases (empty squares) , and closed source with bug report resubmission 
(full diamonds). N u = 1000, N p = 10, S = 1, <j> = 0.9, /3 = 0.1, ui = 0.9, v = 0.9, closed source 
T = 150, average over 100 runs. Continuous lines are for eye-guidance only. 
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Fig. 5. Average time to completion t c versus the number of users (left panel) and the number of 
programmers (right panel). L = 1000, M = 10, 5 = 1, u> = 0.9, v = 0.9; N p = 10 (left panel), 
N u = 1000 (right panel). (f> = 0.9, (3 = 0.1 (diamonds and circles), <f> = 0.7, (3 = 0.3 (squares), and 
4> = 0.6, (i = 0.1 (triangles); average over 100 runs. 



alternate. 

Suppose that the project size S is known in advance and fixed to S = LM. 
What L and M are optimal? Fig. 4 plots (t c ) as a function of M at fixed S = LM 
for open and closed source. It turns out that there is always an optimal value of 
M for any set of parameters or project type, whose position depends on all the 
parameters, and that the plot is much shallower for OSS projects, implying that 
the values of L and M are not crucially important for them.. 

Fig. 5 shows how (t c ) depends on N u and N p : (t c ) is reasonably well fitted by 
ci + C2N~ a with a <~ 1: the rate of improvement is slow as N u increases; even worse, 
it reaches a plateau c\ whose value depends on the number of programmers N p and 
their abilities; the exponent a also depends on the programmers abilities, but not on 
their number. Similarly, adding more programmers decreases (t c ) . In this case, the 
exponent a depends on the number of users, but not on the programmers abilities. 
In other words, hiring more programmers or having more users is an inefficient way 
of improving the speed of debugging when N u or N p is large enough. Interestingly, 
having better programmers decreases (t c ), while the abilities of the maintainer has 
much less dramatic an influence. 

From our model we conclude that bazaar OSS methodology has the shortest 
average time to completion, all other parameters being equal, which is precisely 
the argument of Raymond. 12 However, this does not mean that bazaar OSS is 
always faster: cathedral OSS or CSS projects with a better set of parameters (more 
programmers, better programmers, more users) can outperform bazaar OSS even 
with large time between releases. On the other hand, the quality of bazaar OSS 
programmers does not need to be as high as those of cathedral OSS or CSS projects 
in order to achieve the same time of convergence to the bug-free state. Finally, 
our model suggests that cathedral OSS and CSS projects should try to minimize T 
so as to decrease their convergence time, for instance by implementing automatic 
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Fig. 6. Average number of bugs per part (upper panel) and fraction of defective parts (lower 
panel) versus time in a reconstructed Linux history. M = 20, S = 1, <f> = 0.8, P = 0.05 (thin line) 
P = 0.1 (thick lines), P = 0.2 (dashed line), u> = 0.5, u = 0.5 

upgrades. This of course requires that the users do not perceive a relatively high 
upgrade rate as an indication of low-quality software. 

4. Mathematical analysis 

While it is not possible to solve this model exactly, some understanding can be 
obtained through simple analysis. Bug reports are filled with an average frequency 
of (N u + N p ) ^jjf ■ each user /programmer has a probability D(t)/L to use a part 
that contains at least one bug (by definition of D(t), see page 4), and a probability 
<5-^py/M to report a bug. The probability that exactly two users/programmers 
use the same part and fill bug reports is proportional to (N u + Np)(N u + N p — 
1){5D / L) 2 {(hi/ M) 2 ) d /2 where (}d stands for the average over all the defective 
parts; in later stages of debugging, this probability may be very small for appropriate 
parameters, and redundant bug reporting can be neglected. 

The probabilily that a reported bug is already in the bug list is roughly R(t) /D(t) 
(this assumes that all the defective parts have about the same number of bugs). 
Therefore, the number of relevant bug reports submitted at each time step is about 
(N u + N p ) s ^ff (1 — R(t)/D(t)) on average (without taking into account redundant 
report filling). Finally, neglecting the role of the maintainor, i.e. always accepting 
a patch, the number of bug reports removed from the list at each time step is 
mm[R(t),N p ], hence 

R(t + 1) = R(t) + (N u + N p ) 5 -^(1 - R(t)/D(t)) - mm[R(t), N p ] + n R (t) (3) 

where nji(t) is a white Gaussian noise of zero average. 

The dynamics of the programmers is relatively simple to analyse: assume that 
part i is in the report list and is picked up by a programmer at time t. Then 
(dropping the index) 



b(t + 1) = b{t)<f> + [M - b{t)](i + n(t) 



(4) 
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where n{t) is a noise term of zero average and (n(t)n(t')) = 5 t ,t' — <t>) + (M — 

b(t))(3(l — (3)] where (x) stands for the average of x over time. 

(3M 

which is reached exponentially fast A bug-free state corresponds to 6 = 0. When 
the users do not report imaginary bugs, that is, when P u {b/M) does not contain a 
constant, the boundary b — is absorbing: if there are no more bugs in this part, 
no one will ever be found in it. 

We thus must conclude that the only reason why a bug-free state can be reached 
when the programmers sometimes break working code {(3 > 0) is via fluctuations. 
The fluctuations around b* are of order \[M but b* is of order M, hence, the larger 
M, the more difficult it is to reach b — by chance, which explains why the time 
to completion increases as M increases in Fig. 4. Assuming that M is constant 
and no bias (<f> = 0), it is easy to solve a diffusion equation in the interval [0, M] 
with reflecting boundary at b — M and absorbing boundary at b = with initial 
condition 6(0) = M, which gives 



P(M) 



^E™[sG +2 ") 6 ]^ fe(4+2 " )r * < 6 » 

n>l 1 V 7 J 



where the diffusion constant C oc M. For large times, the survival probability 
S(t) = J2 b P(b, t) decreases as its slowest component, hence 



_ c 



S{t) - VMe-— 1 (7) 

This shows that t c <~ M 3 / 2 for large M in this approximation. Given the fact that 
we did not take into account the potential that attracts 6 around 6*, this is clearly 
an under- estimation. 

Since the number of bug fluctuates around 6* , it is sensible to assume that every 
part with at least one bug has 6* bugs and that it is the number of buggy parts 
that decrease. 

The role of the maintainer is difficult to describe analytically as the formulae are 
cumbersome. But simple approximations bring some light. The average number of 
bugs d(b) detected by the maintainor in a part that contains 6 buggy sub-parts is 
bu+{M—b){l — Lo), with fluctuations a 2 (b) = bv{\ - v) + (M - 6) u (1 - to) . Therefore, 
approximating the probability that the maintainer perceives 6 bugs when there are 
6 bugs by a Gaussian distribution of average d{b) and variance tr(6), the probability 
that a maintainer rejects a patch with 6' buggy sub-parts if the current code has 6 
buggy sub-parts is, in a first approximation, 

P& > 6) . i + r V5^crf ( X -^m dx. (8) 
1 ' 2 ^a{b) 2 V \/2a(6') J V ' 
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d(b) is an increasing function of b if v + u> > 1, i.e., if the maintainor is sufficiently 
gifted. In that case, it is easy to convince oneself that P(b > b) > | if b' > b. If 
v + uu < 1, the fewer the bugs, the more bugs the maintainer thinks there are and 
P(b' > b) < | when b' > b. The special case v + oj = 1 yields simply P(b' > b) = |: 
he tosses a coin in order to determine whether to commit patches or not. In any 
case, the maintainer's role is merely that of a timescalc: depending on his abilities, 
he will delay or speed up the rate of acceptance of good patches, and his quality 
can be defined as P(b' <b\b' <b). 

How to measure (3, <j), uj and v in real data can be done by noting that bi can 
be observed indirectly via the rates of bug reports, which are proportional to the 
density of faulty sub-parts. Dividing the evolution equation of bi (4) by M, one 
obtains the evolution of the density of bugs pi, i.e. the bug reporting rate for part i if 
S = 1 . Estimating (3 and 4> is done by computing the average and the fluctuations of 
all pi(t), conditional on pi(t). Since both of them are proportional to Pi(t), one can 
simply plot these two quantities versus pi for all i, and perform least squares linear 
fits. Once (3 and 4> are known, the parameters of the maintainer can be estimated 
in a similar way. First one should replace all references to bug numbers b and b 
by rates p and p = b/M, etc, in Eq. (8). Then since (3 and <fi are known, one also 
knows P(p'\p) 1 and, for any given estimation of u> and v 1 one can therefore compute 
P(p' > p), which allows for the measure of the maintainer's characteristics. 

5. Dynamics of Linux 

As shown above, the quality of OSS programmers does not need to be as high 
as CSS ones in order to achieve a bug-free state as rapidly all other things being 
equal. However, this does not mean that it can be vanishingly small: the quality 
of OSS programmers in successful projects has a lower bound. As an illustration, 
let us consider the history of Linux. From version 1.0, the number of programmers 
N p (t) can be obtained from the CREDITS file. It is well fitted by a 80 + 0. Id where 
d is the number of days since Linux 1.0. The number of users N u (t) is hard to 
estimate because of the free nature of Linux. Four estimates available on Internet 13 
can be fitted with with a power law N u (y) cx [y — 1991] 3,6 where y denotes the 
year and 1991 is Linux' date of birth. The size S(t) can be measured in number 
of lines divided by the typical number of lines in a subpart; it has been fitted with 
a quadratic function, 14 which is consistent with the linear increase of N p (t), as 
S(t + 1) — S(t) cx N p (t). We can translate S(t) (measured directly in the source 
code) into L{t) and M by supposing that each subpart contains M = 20 lines of 
code. The other parameters that cannot be determined directly from Linux are 
obviously the qualities of the programmers and the maintainors (<5, (3, <j>, us and 
u). In an attempt to be pessimistic, and without prejudice for Linus Tovarlds, we 
considered a random maintainor, that is, uj — v — 1/2, and sub-optimal M; S is 
fixed to 1 . The new parts of Linux are assumed to be first completely buggy. 

Figure 6 shows a transition between two very different behaviors depending 
on the choice of <f> and (3: if the programmers abilities are high enough, Linux 
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converges fast to the slow regime, which is stable with respect to sudden increases 
of the system size, and where the number of bug per part decreases as a function 
time (e.g. 4> = 0.8 and (i = 0.05); if the quality of the programmers is too low, Linux 
falls into the region where the number of bugs makes large excursions (e.g. <f) = 0.8, 
[3 = 0.15), resulting in a dramatic decrease of reliability. Since Linux is known to 
be stable, this shows that the quality of Linux programmers has a lower bound." 
Therefore, super-linear software growth can be sustained if the programmers are 
sufficiently skilled, and if there are enough programmers. The above picture can be 
generalized to any project whose parameters evolve in time. 

6. Outlook 

Our model is designed to be simple and generic so as to provides a generic 
modeling framework. Every simplifying assumption can be remedied. For instance, 
relevant extensions include users that upgrade their program after some delay, for 
instance, only after they have found a bug, or randomly after a new release has been 
released. Heterogeneous rates (6, (3, <fi, u>, v) and part sizes should be drawn from 
a suitable distribution; this will result in non-linearities in Eq. 1. One could also 
impose a restriction on the number of subparts that a programmer is able to review 
in one time-step. An important assumption of the present model is the independence 
of the parts, whereas they are linked by a scale-free asymmetric network, 16,17 hence, 
bugs can propagate on this graph and affect other parts, making debugging harder. 17 
The next step is therefore to study this model on scale-free networks. In addition, 
the number of modifications per programmer is a truncated power-law in Linux, 
as is the number of bugs assigned and corrected per programmer in Mozilla. 15 ' 19 
Therefore it may be possible that the decay of the number of bugs will not be 
exponential anymore, but follow a power-law, as assumed in some reliability growth 
models. 18,3 Assigning a higher or lower bug fixing priority to the parts that have 
more bug reports may interact with the emergence of power-laws in the decrease 
of the number of bugs. Finally, programmers and maintainer could be modelled as 
agents that could learn from their mistakes. All these modifications are likely to 
reveal many fascinating subtleties of bug dynamics and the relationship between 
the micro- and macroscopic levels 
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